1. Field of the Invention
The present invention relates to data processing systems and more particularly, to fault-tolerant simultaneous dynamic graphical and source code editing.
2. Description of the Related Art
In recent years, virtually all personal computers and workstations have adopted a graphical user interface (GUI) environment, which allows the user to manage the system and execute applications using a “point-and-click” method on objects shown on the computer display. The main GUI background is commonly referred to as the “desktop”, and these objects typically include graphic icons, which represent some software application or function, and windows, which divide the desktop into different areas on the display for different applications.
As is well known, computer instructions are written in source code. Although a skilled programmer can understand source code to determine what the code is designed to accomplish, a graphical representation or model of the source code, displayed on the GUI, helps to organize and visualize the structure and components of the software system. The source code “instructs” the GUI regarding what to display. For example, specific source code entries will define an image of a button to be displayed, the color of the button, text to be included within the button, the size of the text, and the like.
Developing a software program involves a continual “write-and-edit” process, whereby a software developer will try out different color schemes, image displays, layouts, and other visual-related aspects of the GUI. To make this process easier, editing tools (“editors”) were developed. Early editors allowed the developer to toggle between the “source code window” (essentially a text editor) and the “GUI window” (a window displaying an editable graphical interpretation of the source code), and required the developer to “refresh” the view that was not being used for the “active editing”. For example, a developer could open the source code window as the active-editing window and would be given read-and-write access to the source code. The developer could then edit the source code to change the GUI's interpretation of the code (e.g., add code to instruct the GUI to display additional objects; modify existing code to instruct the GUI to change a background color; etc.). Once the edits were complete, the developer could then toggle to the GUI window, click on a “refresh” button, and the GUI would attempt to interpret the new source code and display the images associated therewith. If errors existed in the source code, error codes would be generated. In the presence of errors in the source code, some prior art systems deny access to the GUI unless the error in the source code is corrected. In other systems, the GUI is completely blanked out, or an error icon is placed in the GUI forcing the user to go to the source to correct it before it can be displayed/accessed.
Editors exist that allow “GUI-to-source” editing, that is, editing in the GUI window, with the edits being reflected in the source code. Editors also exist that allow “source-to-GUI” editing, that is editing in the source code window, with the edits being applied to the view displayed by the GUI. GUI-to-source editing is sometimes referred to as “top-down” editing; editing from source-to-GUI is sometimes referred to as “bottom-up” editing. Typically, top-down editing is less complex and generates fewer errors, since the changes made in the GUI window can only be made if they are correct. For example, to change the background color of an object in a GUI window, the editor may allow the object to be “right-clicked” to generate a menu of available colors, from which a color is then selected by clicking on the desired color. Code is inserted into the source code file to effect the change. This leaves little room for error, as the changes are selected from a list of acceptable options.
Bottom-up editing is more complex, since source code is in text form and can consist of anything that can be input from a keyboard. Thus, for example, a developer may fail to insert required control codes that are necessary for the language being used (and thus necessary for the GUI to be able to interpret the text), and misspellings and other typographical errors can easily make it into the source code. When the GUI tries to interpret this incorrect source code, errors are generated which can cause the system to disregard all changes, or even crash. Obviously, neither of these options are acceptable.
More recently, “split-screen” editors have been developed that allow the software developer to view both the GUI editing window and the source code editing window simultaneously. In some cases (see for example, U.S. Patent Application Publication No. US-2002-0104071) changes made are synchronized so that a modification in one of the windows is automatically reflected in the other. Thus, using these systems, when a developer makes an accurate edit in the GUI window (top-down editing) the source code is modified automatically. Similarly, when a developer makes an accurate change to the source code via the source code window (bottom-up editing), the change in the source code is automatically interpreted and displayed by the GUI.
While easing a software developer's ability to edit source code/GUI documents, such systems are not without problems. For example, when performing bottom-up editing, the prior-art systems do not tolerate faults or errors in the source code, particularly when the source code is in a high level language, such as JAVA, which requires parsers and compilers to be properly interpreted. If the developer inserts an edit to JAVA source code which is in an improper syntax (e.g., it does not incorporate appropriate JAVA syntax), when the automatic refresh cycle occurs, the GUI window cannot be updated and an error indication is generated. Similar problems occur with semantic errors. In addition, if the developer pauses the input of edits for a time longer than the threshold for the refresh cycle, the system will try to refresh without a complete edit, which can also cause errors. Thus, the developer is required to make all updates quickly and accurately, and cannot see the results of correctly-made changes until any inaccurate edits are corrected.
Accordingly, it would be desirable to have a fault-tolerant editing system that can update the GUI view based on source code edits in such a manner that correct edits are implemented and displayed and incomplete or incorrect edits are ignored.